@wrx7m said in Unlock RDS User Profile Disk (Network Profile):

@dbeato Good thing to have. I just recently migrated to RDS with UPD. Have you checked out Sidder?
https://gallery.technet.microsoft.com/Sidder-Quickly-see-which-fa6360b3

Yeah, Sidder just tells you the VHDX file location and the user but doesn't unmount it and you cannot copy from Sidder the path.

There is a github repo of it here
https://github.com/msfreaks/Sidder

@black3dynamite said in Windows Server 2016 RDS - GPO for Disabling Windows Update Notifications for Non-Admins/Users?:

@wrx7m said in Windows Server 2016 RDS - GPO for Disabling Windows Update Notifications for Non-Admins/Users?:

@black3dynamite said in Windows Server 2016 RDS - GPO for Disabling Windows Update Notifications for Non-Admins/Users?:

@wrx7m Is that a computer configuration or user configuration policy? Try applying the rules to only non-admins groups.

Yeah, it is at the computer level. I would like to do it via user config but I only want them to apply to users on the RD servers. I need to figure out the proper way to structure AD/GPOs to not screw up everything else.

I am guessing creating another OU as a sub container and move the RD servers into.

Edit: Since it isn't GPP, there isn't any item level targeting, so I can't do it that way.

If you can make those changes directly in the registry, maybe can allow you to use GPP and item level targeting.

Hmmm. That makes sense. Let me mull it over.

@wrx7m said in RDS - Suggestions for Migrating User Profiles from Server 2008 R2 to Server 2016 UPD:

@black3dynamite said in RDS - Suggestions for Migrating User Profiles from Server 2008 R2 to Server 2016 UPD:

@wrx7m said in RDS - Suggestions for Migrating User Profiles from Server 2008 R2 to Server 2016 UPD:

@dafyre said in RDS - Suggestions for Migrating User Profiles from Server 2008 R2 to Server 2016 UPD:

@dafyre said in RDS - Suggestions for Migrating User Profiles from Server 2008 R2 to Server 2016 UPD:

@pmoncho said in RDS - Suggestions for Migrating User Profiles from Server 2008 R2 to Server 2016 UPD:

@wrx7m

Just curious, when you chose UPD, did you choose to store all settings or just certain folders?

Some applications don't play nicely with roaming profiles.

UPDs mount at the usual C:\Users\user.name and the applications can't tell a difference.

Right. But, only when the user is logged in. After they logout, that path doesn't exist. I am trying to figure out how to work around that for adding the custom (for each user) erp shortcut on their desktop in their session.

Add the shortcut to C:\Users\Public\Desktop.
That way it will always show up on each user Desktop.

This would be nice and easy, but each user has a custom shortcut- It has a workstation ID in the target path.

https://www.pdq.com/blog/pdq-deploy-and-powershell/
Create a script that creates the shortcut each user Desktop and append the workstation id in the target path.

@pmoncho said in Windows RDS User Profiles - Migrate, Recreate or User Profile Disks?:

@Dashrender said in Windows RDS User Profiles - Migrate, Recreate or User Profile Disks?:

Cool, then you should have it easy.

FYI - Published apps still create a full profile on the RDS box, Just the desktop isn't presented to the user. If the application allows them to browse around, they could typically see the drive letters, the mapped printers, etc... that's why you still need to lock all that stuff down.

Thanks for the info. I will keep that in mind. I was debating about using UPD's like @wrx7m and that was my interest in this post.

Also, still planning out where to put Connection Broker, WebAccess and Licensing but that is another post.

For local profile management, UPDs are a lot cleaner. If we are not putting them on a file server across the network then a second partition/VHDX is set up for that task to keep them separate.

With the inclusion of FSLogix with RDS CALs/SALs now it's a no-brainer, IMNSHO, to set the project up on the FSLogix version.

Storage management is another reason why UPDs on a network or separate partition make sense. Keeping a local profile on the C:\ of the session host is messy and can cause issues down the road with users coming and going.

As far as the Broker/Gateway/Web put those roles on one VM but separate from the Session Host.

@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:

@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:

I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.

The issue is flexibility. Using third party libraries, you can integrate with Excel or with anything else. Using the Office libraries, every user, in ever system, is bound by the limitations of the most problematic. It makes deployments more costly, and more complex.

That's true, it's the kind of self perpetuating lock-in that has served Microsoft so well. People use Excel, and they ask for saving to Excel spreadsheet, so we create the integration specially to allow Excel and not include ODF, then we help keep the industry locked into using Excel because that's all we support unless you want to just save to CSV.

As for the cost and complexity of deployments... that could be true, except that the installation of our main software is already so complex and costly that dealing with potentially installing this library is the easiest part. I think we probably only have one other developer who would be able to figure out how to install it. I've never heard of any client's IT that have been able to figure out how to install it (just calls from those who have tried), client services has to do literally every install.